Metadata-driven switch network control

ABSTRACT

Disclosed are systems and methods to automatically and continuously control a switch network using a metadata-driven switch apparatus. In particular, a switch apparatus, comprised of multiple server-grade processors and co-processors coupled with a switch silicon, has a metadata-driven control program running on the switch apparatus to monitor and control the switch apparatus itself and the network traffic running through the switch apparatus. Furthermore, the switch apparatus and metadata-driven control program monitors the network state (health, behavior, and performance) of the entire switch network and receives feedback from the network to improve switch and network controls. The switch network may be composed of one metadata-driven switch apparatus coupled with one or more other metadata-driven switch apparatuses and may also be composed of one metadata-driven switch apparatus coupled with one or more foreign switch apparatuses.

CLAIM OF PRIORITY

This application is a non-provisional application claiming priority toco-pending U.S. non-provisional patent application Ser. No. 13/726,491titled: “METADATA-DRIVEN SWITCH NETWORK CONTROL,” filed on Dec. 24,2012.

FIELD OF TECHNOLOGY

This disclosure relates generally to networking technology, in oneexample embodiment, to methods and systems to control a switch networkusing a metadata-driven switch.

BACKGROUND

The exponential growth of information consumption through mobilecomputing devices (such as smartphones and tablet computers) has createda greater demand for more robust networking solutions that can handlethe traffic from such devices. Broadband and other data providers arerapidly trying to meet client demands for bandwidth but the challengeremains for server-side operations to meet the immense switch networkingdemands for which enormous datacenters are built. Common switchnetworking elements of a datacenter may require consistent administratorinput to effectively process a flow of data. This flow of data mayexceed 100 gigabits per second (GBPS) in some instances. Common switchnetworking elements may receive commands from a low-level command lineinterface (CLI) utilized by a network administrator to reconfigure theswitching network in order to process a particular flow of data.However, in datacenters with continuously changing types of data andwhere data arrives from an ever changing landscape of locales, therepeated process of reconfiguring through administrator inputs may becumbersome and result in extended network outages and delays. Thesestandardized vendor switches may require complex proprietary applicationprogramming interfaces (APIs) and may be inflexible and static inapplication and configuration.

SUMMARY

Disclosed are systems and methods to automatically and continuouslycontrol a switch network using a metadata-driven switch. In particular,a switch apparatus, comprised of multiple server-grade processors andco-processors coupled with a switch silicon, has a metadata-drivencontrol program running on the switch apparatus to monitor and controlthe switch apparatus itself and the network traffic running through theswitch apparatus. Furthermore, the switch apparatus and metadata-drivencontrol program monitors the network state (health, behavior, andperformance) of the entire switch network and receives feedback from thenetwork to improve switch and network controls. The switch network (alsoknown as a switch fabric) may be composed of one metadata-driven switchapparatus coupled with one or more other metadata-driven switchapparatuses and may also be composed of one metadata-driven switchapparatus coupled with one or more foreign switch apparatuses. Multiplemetadata-driven switches on the network may share the workload ofmanaging the network.

The metadata-driven control program is a metadata switch control engineconstructed using metadata programming methods. The metadata switchcontrol engine utilizes dynamic metadata models of multiplemetadata-driven switches, foreign switches, the entire switch network,and network traffic in combination with a scheduler to make real-timechanges to network configurations in response to changing networktraffic patterns. Network traffic feedback monitoring may beaccomplished by setting multiple flow sensing points (or flow sensors)on the switch (and switch network) to collect packets, which are sent toone or more deep-packet inspection (DPI) engines for analysis. Resultsof the analysis may be forwarded to one or more action methods in acontrol loop action list where the results are classified and applied toissue metadata control commands. Metadata control commands (or metadatacommands) may be collected by the scheduler and sent to a hierarchicalmetadata controller that expands such commands into low-level switchcontrol actions. Such switch control actions may be directed to theswitch apparatus itself, directed to other remote metadata-drivenswitches, or directed to foreign switches.

The objective is to robustly automate the dynamic management of complexnetwork configurations under heavy traffic loads with minimal operationguidance. The distributed metadata-driven control system will monitornetwork health, behavior, and performance moment-to-moment and makeconfiguration changes to eliminate problems and bottlenecks.

In addition, the metadata-driven switch apparatus and process engine mayrun a number of network application endpoints that manage virtual securechannels and provide protected, authenticated, and authorized accessbetween end users and service providers.

The metadata switch control engine (also referred to as themetadata-driven switch engine) may be analogized to an autopilot on afighter jet plane—able to fly the plane and accomplish mission goalswith minimal pilot (e.g., network administrator) input. Like theautopilot, the metadata-driven switch engine can send out thousands,millions, or billions of switch control actions per second to manage thestate of the switch network or fabric in real-time to accomplish networkservice objectives.

In one aspect of the claimed invention, a machine-implemented method toautomatically and continuously control a switch network using metadatacomprises: running a schedule loop at a high rate of repetition using ascheduler, where the schedule loop runs through an action list ofmethods; executing one or more action methods from the action list;passing a metadata command down a metadata command hierarchy in responseto the action method executed; and reconfiguring the switch network inresponse to the metadata command. The switch network comprises a switchconfiguration of a single metadata-driven switch or a switchconfiguration of the single metadata-driven switch communicativelycoupled to one or more foreign switches or one or more remotemetadata-driven switches.

In this aspect, the action list includes one or more static actionmethods, dynamic action methods, virtual secure channel methods, DPIresponse action methods, and remote metadata-driven switch actionmethods. The method also includes performing a deep packet inspection(DPI) of a packet or a packet flow and communicating the results of theDPI to the DPI response action method where the DPI is performed on oneor more off load engines and wherein at least one of the plurality ofoff load engines is coupled to a switch silicon communicatively coupledto the switch network. Additionally, the method involves passing themetadata command down the metadata command hierarchy through ahierarchical metadata controller executable on one or more off loadengines of the single metadata-driven switch.

In this aspect, the metadata command hierarchy may be a series ofexpanding command structures and the hierarchical metadata controllermay receive the action from the action list at a command structure otherthan a top level command structure. Moreover, the series of expandingcommand structures may have direct access to one or more metadata switchmodels of the single metadata-driven switch, one or more metadatanetwork models of the plurality of switches (each composed of a networktraffic model that establishes how traffic should be routed through anetwork), one or more foreign switch models, and one or more ad-hocsettings.

The method may further comprise, in no particular order, reconfiguringthe single metadata-driven switch by passing the metadata command to anopen source switch application programming interface (API);reconfiguring one or more remote metadata-driven switchescommunicatively coupled to the single metadata-driven switch by passingthe metadata command to a remote metadata-driven switch API; andreconfiguring one or more foreign switches communicatively coupled tothe single metadata-driven switch by passing the metadata command to aforeign switch API. Furthermore, the foreign switch or the remotemetadata-driven switch communicatively coupled to the switch network maybe reconfigured through a virtual secure channel.

In addition, when more than one metadata-driven switch is coupled to theswitch network, the method may include delivering a complete copy of apre-existing switch environment to a new metadata-driven switch added tothe switch network through a metadata-driven switch-to-switch protocol.Finally, the method may include reporting a result of one or more actionmethods, metadata commands, and reconfigurations of the switch networkto a network administrator through a web user interface.

Another aspect of the claimed invention involves a switch systemcomprising: a single metadata-driven switch and a plurality of switches,wherein the plurality of switches comprise either one or more foreignswitches or one or more remote metadata-driven switches. The singlemetadata-driven switch has embedded in its switch architecture one ormore off load engines, one or more processors (or co-processors), andone or more storage devices communicatively coupled to the one or moreoff load engines and co-processors. Finally, a plurality of programs isstored in the one or more storage devices, and is executable by the oneor more off load engines and co-processors. At least one of theplurality of programs comprise: instructions to run a schedule loop at ahigh rate of repetition using a scheduler, where the schedule loop runsthrough an action list of methods; instructions to execute one or moreaction methods from the action list; instructions to pass a metadatacommand down a metadata command hierarchy in response to the actionmethod executed; and instructions to reconfigure a switch network inresponse to the metadata command. In this aspect, the switch networkcomprises a switch configuration of the single metadata-driven switch ora switch configuration of the single metadata-driven switchcommunicatively coupled to one or more foreign switches or one or moreremote metadata-driven switches.

Similar to the above method, the action list comprises one or morestatic action methods, dynamic action methods, virtual secure channelmethods, DPI response action methods, and remote metadata-driven switchaction methods. Similarly, the single metadata-driven switch maycomprise a program with instructions to perform a deep packet inspection(DPI) of a packet or a packet flow and communicate the results of theDPI to the DPI response action method. The DPI may be performed on oneor more off load engines and at least one of the one or more off loadengines may be coupled to a switch silicon communicatively coupled tothe switch network.

Similarly, the single metadata-driven switch may comprise a program withinstructions to pass the metadata command down the metadata commandhierarchy through a hierarchical metadata controller executable on oneor more off load engines of the single metadata-driven switch. Asindicated above, the metadata command hierarchy may be a series ofexpanding command structures and the hierarchical metadata controllermay receive the action from the action list at a command structure otherthan a top level command structure. Furthermore, the series of expandingcommand structures may have direct access to one or more metadata switchmodels of the single metadata-driven switch, one or more metadatanetwork models of the plurality of switches (each composed of a networktraffic model that establishes how traffic should be routed through anetwork), one or more foreign switch models, and one or more ad-hocsettings.

Similarly, the single metadata-driven switch may comprise a program withinstructions to reconfigure the single metadata-driven switch by passingthe metadata command to an open source switch application programminginterface (API); instructions to reconfigure one or more remotemetadata-driven communicatively coupled to the single metadata-drivenswitch by passing the metadata command to a remote metadata-drivenswitch API; and instructions to reconfigure one or more foreign switchescommunicatively coupled to the single metadata-driven switch by passingthe metadata command to a foreign switch API. Furthermore, the foreignswitch or a remote metadata-driven switch communicatively coupled to theswitch network may be reconfigured through a virtual secure channel.

Additionally, the single metadata-driven switch may comprise a programwith instructions to deliver a complete copy of a pre-existing switchenvironment to a new metadata-driven switch added to the switch networkthrough a switch-to-switch protocol and a program with instructions toreport a result of one or more action methods, metadata commands, andreconfigurations of the switch network to a network administratorthrough a web user interface.

The methods and systems disclosed herein may be implemented in any meansfor achieving various aspects. Other features will be apparent from theaccompanying drawings and from the detailed description that follows.

BRIEF DESCRIPTION OF THE DRAWINGS

Example embodiments are illustrated by way of example and are notlimited to the figures of the accompanying drawings, in which, likereferences indicate similar elements.

FIG. 1 illustrates a block diagram of a metadata-driven switch used tocontrol a switch network, according to one or more embodiments.

FIG. 2 illustrates a metadata-driven switch engine running on themetadata-driven switch of FIG. 1, according to one or more embodiments.

FIG. 3 illustrates a distributed metadata network, according to one ormore embodiments.

FIG. 4 is a schematic representation of a metadata framework used toconstruct the metadata-driven switch engine of FIG. 2, according to oneor more embodiments.

FIG. 5 is a process flow diagram illustrating the method of controllinga switch network using the metadata-driven switch of FIG. 1.

FIG. 6 is a simplified process flow diagram illustrating the method ofcontrolling a switch network using the metadata-driven switch of FIG. 1.

Other features of the present embodiments will be apparent from theaccompanying drawings and from the detailed description that follows.

DETAILED DESCRIPTION

Disclosed are methods and systems to control a switch network using ametadata-driven switch. Although the present embodiments have beendescribed with reference to specific example embodiments, it will beevident that various modifications and changes may be made to theseembodiments without departing from the broader spirit and scope of thevarious embodiments. It should be understood by one of ordinary skill inthe art that the terms “application(s),” “program(s),” “software,”“software code,” “sub-program(s),” “module(s),” and “block(s)” areindustry terms that refer to computing instructions stored in memory andexecutable by a processor.

Reference is now made to FIG. 1, which illustrates a block diagram of ametadata-driven switch 100 used to control a switch network 118 throughmetadata commands. In one or more embodiments, the metadata-drivenswitch 100 comprises one or more off load engines coupled to one or moreco-processors. In one or more embodiments, an off load engine may be aserver grade processor (e.g., a processor comprising at least 8 coresand operating at a minimum clock speed of 1.8 gigahertz (GHz)). Theco-processors may be additional off load engines (or a processor withequivalent processor power) and may take on processing duties when theprimary off load engines (off load engines 102A and 102B) areoverloaded. It should be understood by one of ordinary skill in the artthat the terms off load engine and co-processors are industry terms thatrefer to computing processors in a physical network switch.

In the example embodiment shown in FIG. 1, the metadata-driven switch100 comprises off load engine 102A and off load engine 102B. In thisembodiment, off load engine 102A is coupled to one or more co-processors108A and off load engine 102B is coupled to one or more co-processors108B. In this same embodiment, the off load engine 102A may also becoupled to a ternary content addressable memory (T-CAM) 110A and the offload engine 102B may also be coupled to another T-CAM 110B. A T-CAMrefers to a form of high-speed memory hardwired with low-level computingapplications or programs. The T-CAM may comprise of both volatile andnon-volatile memory. While the most commonly implemented CAMs are knownas binary CAMs. Such components only search for ones and zeros. A T-CAMallows the processor to access a third state, or “X” state. The X statemay be a “mask,” meaning its value may be anything. This additionalcapability is especially useful for networking operations because whencalculating a subnet address, bits are first masked and then logicaloperations are performed on the rest of the data packet. A networkswitch may store entire routing tables in T-CAM for easy lookup. In oneembodiment, each off load engine embedded in the metadata-driven switch100 may have one or more T-CAMs coupled to the off load engine. In thissame embodiment, one or more T-CAMs (for example, T-CAM 110C in FIG. 1)may store re-writable or upgradeable microcode that may be used toinstruct a switch silicon 112 by translating machine instructions intosequences of circuit-level operations.

Both off load engines 102A and 102B may also be coupled to a sharedmemory 104, which, in turn, may be coupled to one or more storagedevices 106. Shared memory 104 may be any form of non-volatile randomaccess memory (NVRAM) in combination with dynamic random access memory(DRAM) embedded in the metadata-driven switch 100. The shared memory 104may be used to temporarily store data that the one or more off loadengines or co-processors are using for an operation.

Both off load engines 102A and 102B may also be coupled to the switchsilicon 112, which may, itself, be coupled to one or more hostprocessors 114. It is understood by one of ordinary skill in the artthat a switch silicon refers to a switch chip capable of routing networktraffic. In one embodiment, the switch silicon 112 is any switch chipwith at least 64 ports and a minimum aggregate bandwidth throughput of640 gigabits per second (GBPS). The one or more host processors 114 maybe used to operate the switch silicon 112.

The entire metadata-driven switch 100 may be communicatively coupled toa switch network 118 through one or more ports 116A-N connecting theswitch's switch silicon 112 with the switch network 118. All suchcomponents of the metadata-driven switch 100 may be coupled or connectedby high-speed buses shown as solid arrowed lines in FIG. 1.

Although the present embodiments have been described with reference to asingle metadata-driven switch, it will be evident that variousmodifications and changes may be made to these embodiments withoutdeparting from the broader spirit and scope of the various embodiments.For example, multiple metadata-driven switches may be communicativelycoupled to one another or to non-metadata-driven switches (referred tohere as foreign switches) to form a switch system. As will be madeapparent in FIG. 2, the same metadata-driven switch engine 200 used tocontrol a single metadata-driven switch 100 may also be used to controlone or more other metadata-driven switches (referred to here as remotemetadata-driven switches) and one or more foreign switchescommunicatively coupled to the single metadata-driven switch 100.

Reference is now made to FIG. 2, which illustrates a metadata-drivenswitch engine 200 running on the metadata-driven switch 100 of FIG. 1and used to control the switch network 118. The switch network 118 maycomprise a switch configuration of a single metadata-driven switch 100or a switch configuration of the single metadata-driven switch 100communicatively coupled to one or more foreign switches or one or moreremote metadata-driven switches 268. The metadata-driven switch engine200 is a set of software instructions or programs stored in one or moreof the storage devices 106, shared memory 104, or T-CAM 110 of FIG. 1and executable on one or more off load engines (for example, off loadengines 102A and 102B) or one or more co-processors 108. It should beunderstood by one of ordinary skill in the art that metadata models 206,hierarchical metadata controller 216, DPI feedback 226, scheduler 236,and applications 252 may be software modules, blocks, or sub-programsstored on any of the memory or storage devices previously discussedabove (and copied into shared memory 104 when appropriate) and may beexecutable by any one of the off-load engines 102, co-processors 108, orhost processors 114.

As can be seen in FIG. 2, a scheduler 236 runs a schedule loop 249 at ahigh rate of repetition or at potentially real-time rates (meaning thatthe scheduler 236 runs at megahertz (MHz) or GHz rates to mimic the realtime operation of the metadata-driven switch 100). In one embodiment,the scheduler's schedule loop 249 runs continuously through an actionlist 238 of action methods and executes one or more of the actionmethods from the action list. It is important to note that one of theaction methods may be a null method, meaning that the scheduler 236 mayrun through the action list 238 without executing any action methods.The scheduler 236 may be stored initially in on or more storage devices106 and may be copied into the shared memory 104 when being executed bythe off load engine 102.

In the example embodiment depicted in FIG. 2, the action list 238comprises one or more static action methods 240, dynamic action methods242, virtual secure channel (VSC) action methods 244, deep-packetinspection (DPI) action methods 246, and remote switch action methods248. Each action method may be a function called by the scheduler 236.Each action method block may represent one function or a collection offunctions. The static function methods 240 may be a set of functionsthat are called every time the scheduler 236 undertakes a schedule loop249. Such functions or action methods may include low-level maintenanceof the switch or reporting the status of switch to the networkadministrator 302. The dynamic action methods 242 may be a set offunctions that are turned on and off depending on the current status ofthe switch. For example, if a port 116 has failed mechanically, afunction or action method may be called to route all traffic from thatparticular port to a different port. The VSC action method 244 block,the DPI response action method 245 block, and the remote switch actionmethod 248 block will be discussed in various sections below.

In response to an action method executed, the scheduler 236 sends aprocessed metadata command 218 to a hierarchical metadata controller216. The hierarchical metadata controller 216 then passes the metadatacommand 218 down a metadata command hierarchy. This metadata commandhierarchy may be a series of expanding command structures and thehierarchical metadata controller 216 may receive an action or commandfrom the schedule at a top level 220 command structure or a commandstructure level other than the top level 220. The hierarchical metadatacontroller 216 may be stored in the storage devices 106 initially andmay be copied into the shared memory 104 when being executed by one ormore of the off load engines 102.

Additionally, the hierarchical metadata controller 216 may havebi-directional access to one or more metadata models 206. This meansthat the hierarchical metadata controller 216 may read information outof the metadata models 206 while the hierarchical metadata controller216 is executing its metadata command 218 and information may be readback to the metadata models 206 to revise and update one or more of themetadata models 206 to reflect the current configuration of the switchnetwork 118. The metadata models 206 comprises one or more foreignswitch models 208, one or more metadata-driven switch models 210, one ormore network models 212 (each composed of a network traffic model thatestablishes how traffic should be routed through a network), and one ormore ad-hoc settings 214 or ad-hoc network settings. The metadata models206 may be stored in one or more storage devices 106 initially andcopied into shared memory 104 when being executed by a processor.

All such models and settings are constructed from metadata andcharacterize one or more switch configurations that a switch can take.For example, each metadata-driven switch model 210 is constructed frommetadata and is reflective of a potentially live switch configurationthat the metadata-driven switch 100 can take. In addition, each foreignswitch model 208 is also constructed from metadata and is reflective ofa potentially live switch configuration that a foreign switch (forexample, foreign switch 264 as depicted in FIG. 2) communicativelycoupled to one or more metadata-driven switches 100 can take. Finally,each network model is constructed of metadata and is reflective of anoverall network traffic model comprising a plurality of metadata-drivenswitches 100 or one metadata-driven switch 100 and one or more foreignswitches 264. Using metadata to model switch and network configurationsallow the metadata-driven switch engine 200 to rapidly and efficientlyswitch between multiple and numerous switch configurations and ensuresfine-grained network control. For example, the hierarchical metadatacontroller 216 may instruct the metadata-driven switch 100 to switchfrom switch configuration A to switch configuration B by issuing ametadata command 218 to adopt metadata-driven switch model 210B as thelive switch model. Using this method, the switch's configuration changesquicker than if a new switch configuration must be conceived andimplemented by the switch's processor after receiving a traditionalswitch command.

After receiving a metadata command 218, the hierarchical metadatacontroller 216 passes the metadata command 218 down the metadata commandhierarchy by expanding the command at each lower command structurelevel. By doing so, a simple metadata command 218 received at the top ofthe metadata command hierarchy may trickle down into a multitude of morecomplex or detailed commands that are passed as commands to low-levelAPIs to instruct the actual switch silicon to adopt a new switchconfiguration or a new network configuration through the switch andnetwork configuration control output 222. The switch or networkconfigurations chosen may be based on any of the previously discussedforeign switch models 208, the metadata-driven switch models 210, or thenetwork models 212 (which are each composed of a network traffic modelthat establishes how traffic should be routed through a network).

Additionally, the metadata-driven switch engine 200 may adopt one of thead-hoc settings 214. Such settings may be additional switch settingsthat do not reside within a switch model or additional network settingsthat do not reside within any of the switches in a switch network.

In one embodiment, if the hierarchical metadata controller 216 passes acommand to the same metadata-driven switch 100 on which the controlleris resident, it will output a switch control 274 command from the switchand network configuration control output 222 to its switch silicon 112directly through an open source switch API. One example of such an opensource switch API is the OpenFlow interface (depicted in FIG. 2 as OpenFlow API 272) and described in more detail athttp://www.openflowswitch.org. The OpenFlow API 272, the remotemetadata-driven switch API 270, and the foreign switch API 266 may bestored in T-CAM 110C, which may be coupled directly to the switchsilicon 112, and executable by one or more of the host processors 114.

In this same embodiment, if the hierarchical metadata controller 216generates a command for a different metadata-driven switch that is notthe same metadata-driven switch 100 on which the controller is resident(referred to here as a remote metadata-driven switch 268), it willinterface with the remote metadata-driven switch 268 through a virtualsecure channel 224 protocol running as part of the switch and networkconfiguration control output 222. Additionally, the hierarchicalmetadata controller 216 may send the low level switch command throughthe virtual secure channel 224 to a remote metadata-driven switch API270. The remote metadata-driven switch API 270 may then instruct themetadata-driven switch engine running on the remote switch to adopt oneor more metadata-driven switch models stored in its memory.

Finally, if the hierarchical metadata controller 216 generates a commandfor one or more foreign switches 264, it may interface with the foreignswitch 264 through a foreign switch API 266 that may send lines ofsoftware code to the foreign switch 264 in its native programminglanguage. Communications with both foreign switches 264 and remotemetadata-driven switches 268 are transacted through the virtual securechannel 224 to ensure the security of resources sent to and receivedfrom such switches. For example, the virtual secure channel 224 protocolto one or more foreign switches 264 may involve the exchange ofencrypted software token (ESTs). At this juncture, it is important topoint out that the remote metadata-driven switch 268 refers to anymetadata-driven switch 100 that is not the metadata-driven switch 100running the metadata-driven switch engine 200 and implementing theswitch control 274 command at present.

Moreover, since all metadata-driven switches of this switch system run acopy of the same metadata-driven switch engine 200, the distinctionbetween remote metadata-driven switch 268 and metadata-driven switch 100is simply a matter of perspective. With that said, since eachmetadata-driven switch 100 runs a copy of the metadata-driven switchengine 200, a network of such switches allow control of the switchnetwork to be distributed over multiple metadata-driven switches so thatif any such switch fails or is compromised by a threat agent, anotherswitch can take over essential switch control functions without delay.Therefore, adding additional metadata-driven switches to the switchnetwork offers the network with more redundancy, more fault tolerance,and more overall processing power for tasks such as DPI.

A metadata-driven switch receiving a command from anothermetadata-driven switch (or a remote metadata-driven switch) first sendsthe command (depicted in FIG. 2 as command from remote switch 250) tothe remote switch action method 248 block before it can be acted on bythe scheduler 236 and, eventually, the hierarchical metadata controller216. The remote switch action method 248 block analyzes any commandsreceived from the remote metadata-driven switch 268 and makes adetermination whether the command is allowable before sending thecommand to the hierarchical metadata controller 216.

In fact, FIG. 2 also depicts how the meta-driven switch engine 200 maybe leveraged to continuously monitor the state of a switch networkthrough DPI feedback. As indicated in FIG. 2, a DPI engine (shown hereas DPI feedback 226) comprises a DPI processing 230 block and a DPIapplication control 232 block. In one embodiment, the DPI feedback 226block or sub-program may be stored in the storage devices 106 (andcopied into shared memory 104 when appropriate) and executable by adedicated off load engine (such as off load engine 102A). In anotherembodiment, the DPI feedback 226 block or sub-program may be stored inthe storage devices 106 (and copied into shared memory 104 whenappropriate) and executable by one or more co-processors 108.

The DPI application control 232 block receives feedback from a varietyof flow sensors established throughout switching nodes in the switchnetwork. The flow sensor may sense information regarding a packet orinformation regarding a flow of packets. The information from such flowsensors may be first sent to the DPI application control 232 block andthen processed by the DPI processing 230 block. The DPI processing 230block may then perform a deep packet inspection of one or more packetsor one or more packet flows sampled from the flow sensors andcommunicate the results of the DPI through either the DPI processing 230block or one or more virtual secure channels. If the packets inspectedare encrypted packets, the result of such an inspection may becommunicated to the VSC action method 244 block through one or morevirtual secure channels (for example, virtual secure channel 228). Ifthe packets inspected are non-encrypted packets, the result of such aninspection may be communicated to the DPI response action method 246directly. Both the VSC action method 244 block and the DPI responseaction method 246 block may comprise a collection of functions that maybe called in response to a result gleaned from DPI feedback 226. Suchfunctions may instruct the metadata-driven switch 100 to route trafficto different ports or to drop or sequester certain packets or packetflows that pose a threat to the switch network 118.

In one example embodiment, several DPI processing methods may be storedin the DPI processing 230 block and different DPI processing methods maybe communicated to the DPI response action method 246 block to beexecuted by the scheduler 236. In one embodiment, the deep packetinspection is performed on at least one of the off load engines 102A and102B communicatively coupled to the switch silicon 112.

By doing so, the metadata-driven switch engine 200 establishes anoverall control loop (depicted in FIG. 2 as control loop 251) wherefeedback from DPI is one of the factors that instigate changes to aswitch network. For example, as depicted in FIG. 2, feedback is firstcollected from the metadata-driven switch 100, then processed by the DPIengine (DPI feedback 226) and communicated to the scheduler 236.Metadata commands in response to such feedback are then communicated tothe hierarchical metadata controller 216, which then passes a packetsampling control 276 command back down to the metadata-driven switch 100through the OpenFlow API 272. Such packet sampling control commands mayinclude a command to adopt a new flow sensor configuration or a newmechanism for collecting flow information.

Alternatively, the scheduler 236 may also receive commands from remotemetadata-driven switches or from foreign switches. The responses to suchfeedback are communicated as action methods to the scheduler 236 via oneor more virtual secure channels. Since the scheduler 236 continuouslyand automatically loops through its action list 238 at MHz to GHz rates,the configuration of the metadata-driven switch 100, the configurationof the switch network 118 (which may include both foreign switches 264and remote metadata-driven switches 268), and the models stored in themetadata models 206 are continuously updated to take into account newfeedback.

Finally, the metadata-driven switch 100 may send a data packet to beprocessed 260 to one or more on-switch applications 252 stored in one ormore storage devices 106 of the metadata-driven switch 100 (and copiedinto shared memory 104 when appropriate) and executable by one or moreof the co-processors 108. As depicted in FIG. 2, the applications mayinclude a deep-packet inspection (DPI) 253 application, an applicationthat establishes a virtual secure channel 254, a key managementapplication 255, an authentication, authorization, and accounting 256application, a DPI application control 258 and other applications257A-N. Examples of other applications 257A-N may include securityprotocols to securely route traffic from financial institutions and toanalyze data packets received from such institutions. Another example ofother applications 257A-N may include security protocols to securelyroute enterprise traffic from client devices used by employees of anenterprise.

The DPI 253 application may be additional DPI processes not covered bythe DPI feedback 226 sub-program. One or more of the applications 252may process a packet and send the processed packet 262 back to themetadata-driven switch 100 to be delivered to its intended destination.One example of such an application is the virtual secure channel 254application, which may be used to open one or more virtual securechannels to an enclave device coupled to a client device (e.g., asmartphone or computer). Additionally, the key manage 255 block and theauthenticate, authorize, and accounting 256 block may also be used toexchange ESTs with one or more devices communicating with ametadata-driven switch 100 or a foreign switch 264 communicativelycoupled to the metadata-driven switch 100. Such an application allowsthe metadata-driven switch 100 to perform a security function inaddition to a switching function.

One or more such on-switch applications 252 may be stored in one or morestorage devices 106 (and copied into shared memory 104 when appropriate)and executed by the one or more co-processors 108.

Throughout this entire process, a user (such as a network administrator302, see FIG. 3) may view or control any components of themetadata-driven switch engine 200 through a web user interface (UI) 202.The web UI 202 allows the network administrator 302 to examine the stateof the network or the state of any network traffic. In one embodiment,the web UI 202 may interface with any of the metadata models 206, thehierarchical metadata controller 216, the DPI feedback 226, thescheduler 236, or the applications 252. For example, the networkadministrator 302 may examine how the hierarchical metadata controller216 is set up and what happens when a metadata command 218 is passeddown and expanded through the metadata command hierarchy using the webUI 202. Additionally, the network administrator may input a commanddirectly to the hierarchical metadata controller 216 without goingthrough the scheduler 236. Similarly, a network administrator 302 mayadd a model to any of the metadata models 206 and may revise any of themodels stored in the metadata models 206 block. Furthermore, a networkadministrator 302 may examine the setup of the scheduler 236 and addactions to the action list 238 through the web UI 202.

The web UI 202 interfaces with the switch engine's sub-programs througha RESTful interface 204. This interface is based on the RepresentationalState Transfer (REST, also known as RESTful) software architecture stylewhich relies on an HTTP or HTTPS protocol to give users access to remotedata and remote resources. In another embodiment not shown in FIG. 2,the web UI 202 may interface directly with the plurality of sub-programswithout going through the RESTful interface 204. In one embodiment, theweb UI 202 comprises of web pages or web applications that display theresults of all sub-programs included in the metadata-driven switchengine 200 and allow the user to input commands directed at each of thesub-programs. One or more off load engines 102 may also run an Apacheweb server (or some other web server), for example, to allow clientdevices access to the metadata-driven switch 100.

Reference is now made to FIG. 3, which illustrates a distributedmetadata network 300 according to one or more embodiments. As indicatedabove, all of the metadata-driven switches (metadata-driven switch100A-N) are running the metadata-driven switch engine 200. Additionally,as described above, a metadata-driven switch engine 200 considers ametadata-driven switch that is not the switch on which its program iscurrently running as a remote metadata-driven switch 268. As indicatedin FIG. 3, a network of such switches (switch network 118) allowscontrol of the network to be distributed over multiple metadata-drivenswitches so that if any such switch fails or is compromised by a threatagent, another switch can take over essential switch control functionswithout delay. This allows the network to be run as a distributedmetadata network 300 using, essentially, a single metadata-driven switchengine 200.

In one embodiment, a network model 212 may be established where onemetadata-driven switch 100 acts as the master switch and all otherswitches on the switch network 118 act as the slave to the masterswitch. In another embodiment, a network model 212 may be establishedwhere control is distributed evenly over multiple meta-driven switches100A-N and decisions are made by factoring in commands from allswitches. Finally, in a further embodiment, a network model 212 may beestablished as a tree structure where one metadata-driven switch 100delivers commands to only a few metadata-driven switches, which may, inturn, deliver commands to more switches in the switch network 118. Allsuch network models 212 also comprise network traffic models thatestablish how traffic should be routed through a network.

The network administrator 302 may choose the appropriate network model212 by inputting a network control command through the web UI 202.

Moreover, a complete copy of the pre-existing switch environment (themetadata-driven switch engine 200) may be delivered to a newmetadata-driven switch added to the switch network 118 through ametadata-driven switch-to-switch protocol. In one embodiment, thisswitch-to-switch protocol is the remote metadata-driven switch API 270.As shown in FIG. 3, the switch network 118 may also comprise foreignswitches 264A-N. A switch network comprising of just one metadata-drivenswitch 100 may control a plurality of foreign switches 264A-N simply bysending switch commands through the foreign switch API 266.

When new switches are added to the switch network 118, themetadata-driven switch engine 200 adds new network models 212 to themetadata models 206 block and the number of network models 212 grows byaccretion.

Reference is now made to FIG. 4, which is a schematic representation ofa metadata framework used to construct the metadata-driven switch engineof FIG. 2 according to one or more embodiments. While one traditionaldefinition of “metadata” is “data about data,” the claimed inventionrefers to metadata much more broadly, as “data about everything.” Forexample, metadata is used in the claimed invention to annotate: data,states of data (or simply, states), functions involving data (or simply,functions), and processes involving data (where a process may alsorepresent the behavior of a state). Thus, a collection of metadata maybe used to annotate and index any number of simple to complex “things.”And any simple to complex things may be decomposed and indexed usingmetadata. When used to index a thing and its components, the metadataindex may be considered a model of that thing and can capture thething's behavior.

Since software may be defined as an organized collection of data andinstructions, software may also be treated as a “thing” that can beindexed (or decomposed) using metadata. A more object-orienteddefinition of software is that software are procedures built usingobjects, which are further composed of states and methods (or functionsfor manipulating states). In other words, a state is simply structureddata and methods or procedures are lower to higher-level organizedcollections of instructions.

New metadata software models may be easily (and quickly) built (orcomposed) using the software's metadata annotations and any metadatasoftware model may become metadata primitives in a higher level metadata“domain” or “functional domain” (thereby allowing metadata to describeother metadata). From a software perspective, a functional domain 400identifies a function state or function space upon which programs (alsocalled functional domain programs 402) can be expressed. A typicalprogram will employ elements from multiple functional domains 400. Afunctional domain 400 can be decomposed into a set of domain states andfunctions (depicted in FIG. 4 as domain metadata 404 and domainfunctions 406, respectively), which can be indexed with metadataannotations. A basis set of domain states and functions are said tocompletely span the functional domain 400—thus, giving metadata accessto every state and operation on that functional domain 400. Metadataindexed domain metadata 404 and domain functions 406 enable theconstruction of new metadata models of programs on that domain (depictedas constructed programs 410 in FIG. 4) as well as enabling thereconstruction of functional domain programs 402 on the functionaldomain 400.

A metadata script language is required to bring metadata software modelsto life (that is, to make them executable). A metadata script languagemay be a declaration specification language that enables the expressionand execution of the metadata software models. The metadata scriptlanguage is oftentimes a specification language and closely resemblesthat of plain English. In this case, a metadata language may be acluster of Domain Specific Languages (DSLs) or a cluster of smalllanguages joined together with the same underlying metadata languagesyntax to enable them to blend and work together.

A metadata-driven software approach simplifies and accelerates softwaredevelopment. The first step of this approach is to identify anappropriate functional domain 400. The next step involves decomposingthe functional domain into sets of domain metadata 404 and domainfunctions 406. In the claimed invention, the domain metadata 404 may bea set of metadata domain APIs and the domain functions 406 may be anappropriate low-level programming language (such as the foreign switchAPI 266 or the remote metadata-driven switch API 270). Finally, ametadata script language is applied to compose executable metadataprogram models (the constructed programs 410 and reconstructed programs408). Additionally, the metadata script language itself may be builtusing metadata, which means it may have its own language-interpreter orcompiler specific metadata annotated and indexed into functionaldomains.

With regard to the claimed invention, each DSL may implement a differentfunctional domain 400. For example, the metadata-driven switch engine200 may be constructed of multiple functional domains 400. For example,the DPI feedback 226 block may be one functional domain and thehierarchical metadata controller 216 may be another functional domain.Additionally, each of the different metadata-driven switch models 210and foreign switch models 208 may each be considered a separatefunctional domain 400. Finally, each of the virtual secure channels 228may be treated as a separate functional domain.

From an implementation standpoint, metadata may be implemented as acollection of name-value pairs having type. The name portion may beplain text. The value part may be simple or complex (chosen at thediscretion of the programmer). A value can be a basic primitive scalarvalue, that is: a Boolean, a number, or a text string. Or value can be arecord or an object (with more or less internal complexity). A recordmay also be an n-tuple of named primitive values. Additionally, a valuemay include lists, arrays, hashes, or graphs of primitive values and/orobjects. Or the lists, arrays, hashes, or graphs can hold sub-lists,sub-arrays, or sub-graphs. Or a value can be an additional metadatainstance or list, array, hash, or graph of a metadata instance.

A metadata implementation framework must also incorporate bookkeepinginformation about metadata instances into the metadata structure.Bookkeeping information holds identification index numbers, create andchange dates, access controls, ownership, and other informational items.Bookkeeping information is foundational (that is, structural-level)primitive information about metadata that is important to themaintenance and management of the metadata system.

Type is structural metadata about metadata. Type identifies the kind orstructure of metadata instances. Since metadata is extendable, type maybe extendable to add new metadata type instances as new metadata kindsare added to the metadata system. New metadata kinds are identified andadded to the system by adding new metadata types. A type must identifythe kind of value that a metadata instance holds and the domain to whicha metadata instance belongs. An index of types will annotate all thedomains and value types in the metadata system.

At the system level, a metadata instance is an object or record thatholds bookkeeping information, a type metadata reference, a name, and avalue. An object is essentially a record with added methods (ignoringthe object compositional potential of objects—objects may be composedfrom other objects in a ‘has’ compositional relationship in addition tothe more advertised ‘is-a’ inheritance relationship).

Finally, the set of states, functions, processes for any domain orfunctional domain 400 may be extended at any time with new metadatadescribing a new state, function, or process without disrupting oldermetadata software models. This establishes an accretion model forsoftware development where any previously reconstructed program 408 orconstructed program 410 is compatible with newly reconstructed programs408 and constructed programs 410.

Reference is now made to FIG. 5, which is a process flow diagramillustrating the method of controlling a switch network 118 using themetadata-driven switch 100 of FIG. 1. Specifically, operation 500involves running a schedule loop at a high rate of repetition, whereinthe schedule loop runs through an action list of methods. Operation 502involves executing one or more action methods from the action list.Sub-operation 504 of operation 502 involves performing a deep packetinspection (DPI) of a packet or a packet flow and communicating theresults of the DPI to a DPI response action method. Operation 506involves passing a metadata command in response to the action methodexecuted to a hierarchical metadata controller 216. Operation 508involves reconfiguring a single metadata-driven switch 100 by passingthe metadata command to an open source switch application programminginterface (API) such as the OpenFlow API. Operation 510 involvesreporting a result of one or more action methods, metadata commands, andreconfigurations of the switch network to a network administrator 302.

Reference is now made to FIG. 6, which is a simplified process flowdiagram illustrating the method of controlling a switch network 118using the metadata-driven switch 100 of FIG. 1. Specifically, operation600 involves running a schedule loop at a high rate of repetition usinga scheduler wherein the schedule loop runs through an action list ofmethods. Operation 602 involves executing one or more action methodsfrom the action list wherein one of the action methods is a null method.Operation 604 involves passing a metadata command 218 down a metadatacommand hierarchy in response to the action method executed. Operation606 involves reconfiguring the switch network in response to themetadata command wherein the switch network 118 comprises a switchconfiguration of the single metadata-driven switch 100 communicativelycoupled to one or more foreign switches 264 or one of more remotemetadata-driven switches 268.

A number of embodiments have been described. Nevertheless, it will beunderstood that various modifications may be made without departing fromthe spirit and scope of the claimed invention. In addition, the logicflows depicted in the figures do not require the particular order shown,or sequential order, to achieve desirable results. In addition, othersteps may be provided, or steps may be eliminated, from the describedflows, and other components may be added to, or removed from, thedescribed systems. Accordingly, other embodiments are within the scopeof the following claims.

It may be appreciated that the various systems, methods, and apparatusdisclosed herein may be embodied in a machine-readable medium and/or amachine accessible medium compatible with a data processing system(e.g., a computer system), and/or may be performed in any order.

The structures and modules in the figures may be shown as distinct andcommunicating with only a few specific structures and not others. Thestructures may be merged with each other, may perform overlappingfunctions, and may communicate with other structures not shown to beconnected in the figures. Accordingly, the specification and/or drawingsmay be regarded in an illustrative rather than a restrictive sense.

What is claimed is:
 1. A machine-implemented method to control a switchnetwork, comprising: running a schedule loop using a scheduler, whereinthe schedule loop runs through an action list of methods; executing oneor more action methods from the action list; passing a metadata commanddown a metadata command hierarchy in response to the action methodexecuted; and reconfiguring the switch network in response to themetadata command, wherein the switch network comprises a switchconfiguration of a single metadata-driven switch, or a switchconfiguration of the single metadata-driven switch communicativelycoupled to one or more foreign switches or one or more remotemetadata-driven switches.
 2. The method of claim 1, wherein the actionlist comprises one or more static action methods, dynamic actionmethods, virtual secure channel methods, DPI response action methods,and remote metadata-driven switch action methods.
 3. The method of claim2, further comprising: performing a deep packet inspection (DPI) of apacket or a packet flow and communicating the results of the DPI to theDPI response action method, wherein the DPI is performed on one or moreoff load engines and wherein at least one of the off load engines iscoupled to a switch silicon communicatively coupled to the switchnetwork.
 4. The method of claim 1, further comprising: passing themetadata command down the metadata command hierarchy through ahierarchical metadata controller executable on one or more off loadengines of the single metadata-driven switch.
 5. The method of claim 4,wherein the metadata command hierarchy is a series of expanding commandstructures and the hierarchical metadata controller receives the actionfrom the action list at a command structure other than a top levelcommand structure.
 6. The method of claim 5, wherein the series ofexpanding command structures has direct access to one or more metadataswitch models of the single metadata-driven switch, one or more metadatanetwork models of the plurality of switches, one or more foreign switchmodels, and one or more ad-hoc settings.
 7. The method of claim 1,further comprising: reconfiguring the single metadata-driven switch bypassing the metadata command to an open source switch applicationprogramming interface (API); reconfiguring one or more remotemetadata-driven switches communicatively coupled to the singlemetadata-driven switch by passing the metadata command to a remotemetadata-driven switch API; and reconfiguring one or more foreignswitches communicatively coupled to the single metadata-driven switch bypassing the metadata command to a foreign switch API.
 8. The method ofclaim 7, further comprising: reconfiguring the foreign switch or theremote metadata-driven switch communicatively coupled to the switchnetwork through a virtual secure channel.
 9. The method of claim 1,further comprising: delivering a complete copy of a pre-existing switchenvironment to a new metadata-driven switch added to the switch networkthrough a metadata-driven switch-to-switch protocol.
 10. The method ofclaim 1, further comprising: reporting a result of one or more actionmethods, metadata commands, and reconfigurations of the switch networkto a network administrator through a web user interface.
 11. A switchsystem, comprising: a single metadata-driven switch and a plurality ofswitches, wherein the plurality of switches comprise one or more foreignswitches or one or more remote metadata-driven switches; a plurality ofoff load engines and processors embedded in the single metadata-drivenswitch; a plurality of storage devices communicatively coupled to theplurality of off load engines and processors; a plurality of programs,wherein the plurality of programs are stored in the plurality of storagedevices and executable by the plurality of off load engines orprocessors, with at least one of the plurality of programs comprising:instructions to run a schedule loop using a scheduler, wherein theschedule loop runs through an action list of methods; instructions toexecute one or more action methods from the action list; instructions topass a metadata command down a metadata command hierarchy in response tothe action method executed; and instructions to reconfigure a switchnetwork in response to the metadata command, wherein the switch networkcomprises a switch configuration of the single metadata-driven switch,or a switch configuration of the single metadata-driven switchcommunicatively coupled to one or more foreign switches or one or moreremote metadata-driven switches.
 12. The switch system of claim 11,wherein the action list comprises one or more static action methods,dynamic action methods, virtual secure channel methods, DPI responseaction methods, and remote metadata-driven switch action methods. 13.The switch system of claim 12, further comprising: instructions toperform a deep packet inspection (DPI) of a packet or a packet flow andcommunicate the results of the DPI to the DPI response action method,wherein the DPI is performed on one or more off load engines and whereinat least one of the off load engines is coupled to a switch siliconcommunicatively coupled to the switch network.
 14. The switch system ofclaim 11, further comprising: instructions to pass the metadata commanddown the metadata command hierarchy through a hierarchical metadatacontroller executable on one or more off load engines of the singlemetadata-driven switch.
 15. The switch system of claim 14, wherein themetadata command hierarchy is a series of expanding command structuresand the hierarchical metadata controller receives the action from theaction list at a command structure other than a top level commandstructure.
 16. The switch system of claim 15, wherein the series ofexpanding command structures has direct access to one or more metadataswitch models of the single metadata-driven switch, one or more metadatanetwork models of the plurality of switches, one or more foreign switchmodels, and one or more ad-hoc settings.
 17. The switch system of claim11, further comprising: instructions to reconfigure the singlemetadata-driven switch by passing the metadata command to an open sourceswitch application programming interface (API); instructions toreconfigure one or more remote metadata-driven communicatively coupledto the single metadata-driven switch by passing the metadata command toa remote metadata-driven switch API; and instructions to reconfigure oneor more foreign switches communicatively coupled to the singlemetadata-driven switch by passing the metadata command to a foreignswitch API.
 18. The switch system of claim 17, further comprising:instructions to reconfigure the foreign switch or the remotemetadata-driven switch communicatively coupled to the switch networkthrough a virtual secure channel.
 19. The switch system of claim 11,further comprising: instructions to deliver a complete copy of apre-existing switch environment to a new metadata-driven switch added tothe switch network through a switch-to-switch protocol.
 20. The switchsystem of claim 11, further comprising: instructions to report a resultof one or more action methods, metadata commands, and reconfigurationsof the switch network to a network administrator through a web userinterface.